feat(kms-auth)!: pass the TEE platform to policies and allow restricting it - #1567

…ing it

One OS image hash can boot on several TEE platforms (a release ships both
TDX and SEV-SNP firmware), and app keys derive from the app ID alone, so an
app approved on bare-metal TDX could be served on any platform the KMS
enables. The KMS already sends teeVariant; auth-eth dropped it.

- Append teeVariant, the platform name the KMS reports, to the
  AuthorizationRequest of IAppEpochAuth. auth-eth passes it through
  unchanged, so the KMS defines the names and each policy picks its own
  representation. AppInfo is unchanged, so DstackKms still forwards it as
  is to policies without IAppEpochAuth.
- DstackApp and DstackKms allow any platform until the owner calls
  setAllowAnyTeeVariant(false), then only the names set by
  setAllowedTeeVariants. TeeVariantPolicy keeps them as one packed slot: a
  restricted flag and a bitmask over the platform names it hardcodes, so a
  check costs one read; listing an unknown name reverts, and a restricted
  policy refuses one. The policy covers every epoch: which platforms may hold
  keys is a trust decision, not a property of a key generation. A restricted
  policy refuses the legacy isAppAllowed/isKmsAllowed, whose callers report
  no platform; the 0.6.x KMS also serves SEV-SNP and Nitro, so they cannot
  be taken as TDX.
- auth-eth requires teeVariant on /authorizeKms and /authorizeApp.
- Manage.s.sol SetKmsTeeVariants/SetTeeVariants take TEE_VARIANTS=any or a
  list of names and refuse an empty one; Query.s.sol prints the policies.

DstackKms stays under the EIP-170 limit at 24,041 bytes.

BREAKING CHANGE: unreleased ABI only: authorizeKms/authorizeApp, and the
IAppEpochAuth and IAppEpochManagement (now 0x8c0524c4) interface IDs.

Signed-off-by: Kevin Wang <wy721@qq.com>